Method and Apparatus for Remotely Monitoring the Condition of a Patient

ABSTRACT

A patient monitoring system provides enhanced functional capability relative to known systems and provides a wireless communication link between a patient monitoring device, worn by a patient, and a local hub. The patient monitoring system is adapted to monitor various patient physiological characteristics, such as blood pressure, pulse rate, blood glucose, weight, pulse oximetry and others. The data from the patient monitoring device is wirelessly transmitted to a local hub, which, in turn, is configured to automatically transfer the data to a remote server, for example, over a public or private communications network. In one embodiment of the invention, the server is configured as a web portal to selectively allow access to such patient physiological data by designated third parties, such as physicians, clinicians, relatives and the patient themselves.

RELATED APPLICATIONS

This is a continuation application which claims the benefit and priorityof U.S. patent application Ser. No. 10/414,326, filed Apr. 15, 2003,which claimed the benefit of U.S. provisional application No.60/372,894, filed on Apr. 16, 2002.

BACKGROUND OF THE INVENTION Computer Listing Appendix

This application includes a Computer Listing Appendix on compact disc,hereby incorporated by reference.

1. FIELD OF THE INVENTION

The present invention relates to a patient monitoring system and moreparticularly to a patient monitoring system for monitoring variousphysiological characteristic data of a patient, such as blood pressure,pulse rate, blood glucose, weight and others, which wirelessly transmitssuch data to a hub, located near the patient, which, in turn transfersthe data automatically to a remote server, for example, over a public orprivate communications network, which, in one embodiment, the remoteserver is configured as a web portal which selectively allows access topatient data by selected third party users, such as physicians,clinicians, patients, and/or relatives, and, in addition providesincreased functionality relative to known systems by enabling trends ofthe patient data to be developed as well as automatically generatecommunications with the patient or other third parties by way of e-mailor pager when predetermined thresholds for selected physiologicalcharacteristics are exceeded and/or to remind the patient to takephysiological measurements.

2. DESCRIPTION OF THE PRIOR ART

Healthcare costs have been increasing at a tremendous rate for the pastdecade, far exceeding the rate of inflation. The compound average growthrate for healthcare spending over the past decade was 6%, amounting tonearly $1.3 trillion in the year 2001. Chronic disease patients, whosenumbers have doubled during the same decade, account for nearly $700billion of this spending. Managed care organizations have begun to seekhelp from disease management companies to contain the spending onchronic diseases. Disease management companies thus have developedsystems to monitor the chronically ill patients and help lowerhealthcare spending by improving patient compliance to medicationschedules thereby lowering the hospitalization rates.

Various types of patient monitoring systems are known. For example, U.S.Pat. Nos. 5,810,747 and 5,694,940 disclose patient monitoring systems inwhich the patient monitoring devices are hard wired to a local hub,which, in turn, is connected to a remote station, for example, over acommunication network. The fact that the patient monitors are hard wiredto the local station significantly reduces the utility of such systems.For example, such systems are obviously not suitable for ambulatorypatients and many applications where it may be desired to remotelymonitor the physiological characteristics of a patient outside of anon-clinical environment.

Accordingly, various systems have been developed in which the patientmonitoring device, normally worn by a patient, is connected by way of awireless link to a local hub, which, in turn, is connected to a remotestation or server by way of a public communication network, such as thePlain Old Telephone System (POTS). Examples of such systems aredisclosed in U.S. Pat. Nos. 3,882,277; 5,522,396; and 6,093,146. Each ofthese systems include a patient monitoring device, connected to a localhub by way of a wireless link, which, in turn, is connected to a remoteserver by way of a public communication link, such as POTS. Such systemsdepend on the use of telephone modems which require patients to place aphone receiver into a modem cradle and dial up the remote server. Suchsystems have been found to be far too complicated and difficult forelderly and critically ill patients.

In order to resolve this problem, patient monitoring systems, forexample, as disclosed in U.S. Pat. No. 6,336,900, have been developed,which not only provide a wireless link between the patient monitor andthe local hub, but also automatically dial and connect to the remoteserver to facilitate the transfer of the physiological data to theremote server. Unfortunately, the functional capability of such systemsis relatively limited. For example, such systems only provide limitedaccess to the patient data. In addition, such systems can not be used toprovide reminders to patients to take readings or provide messages tothe patients or third parties when the physiological characteristics ofa patient exceed predetermined thresholds. Thus, there is a need for apatient monitoring system for monitoring the physiologicalcharacteristics of a patient that provides enhanced functionality andexpanded access to the healthcare data while not tethering the patientto a local hub, thereby improving patient compliance, affording thehealthcare provider the ability to capture adverse events sooner andavoid costly emergency care and reduce costly home health visits.

SUMMARY OF THE INVENTION

Briefly, the present invention relates to a patient monitoring systemwhich provides enhanced functional capability relative to known systemsand provides a wireless communication link between a patient monitoringdevice, worn by a patient, and a local hub. The patient monitoringsystem in accordance with the present invention is adapted to monitorvarious patient physiological characteristics, such as blood pressure,pulse rate, blood glucose, weight, pulse oximetry and others. The datafrom the patient monitoring device is wirelessly transmitted to a localhub, which, in turn, is configured to automatically transfer the data toa remote server, for example, over a public or private communicationsnetwork. In one embodiment of the invention, the server is configured asa web portal to selectively allow access to such patient physiologicaldata by designated third parties, such as physicians, clinicians,relatives and the patient themselves. In accordance with anotherimportant aspect of the invention, the system provides for enhancedfunctionality relative to known systems and allows trends of thephysiological data to be selectively generated. In addition, any thirdparty can set thresholds to automatically notify the patient or otherthird parties by various communication methods including e-mail and/orpager when a particular physiological characteristic exceeds apredetermined threshold. The system is also configured to providereminders to patients to take readings.

DESCRIPTION OF THE DRAWINGS

These and other advantages of the present invention will be readilyunderstood from the following specification and attached drawingwherein:

FIG. 1 is a block diagram of the patient monitoring system in accordancewith the present invention.

FIG. 2 is a block diagram of an alternate embodiment of the invention,illustrated in FIG. 1, illustrating the use of the invention in amulti-user, multi-hub environment.

FIG. 3 is a block diagram of an alternate embodiment of the invention,illustrated in FIG. 1, for a multi-user environment, single hubenvironment.

FIG. 4 is a block diagram of another alternate embodiment of theinvention illustrated in FIG. 1 for a multi-user, single hubenvironment.

FIG. 5 is a block diagram of an exemplary physiological transducer forrelatively complex transducers such as an electrocardiograph for usewith the present invention.

FIG. 6 is a block diagram of exemplary self contained hub or basestation for use with the present invention.

FIG. 7 is an exemplary schematic diagram of a relatively simplephysiological transducer such as a blood pressure monitor, for use withthe present invention.

FIG. 8 is an exemplary schematic diagram of an alternative hub or basestation that is adopted to be connected to a middleware device, for usewith the present invention.

FIG. 9A is a schematic diagram of the hub illustrated in FIG. 6.

FIG. 9B is a schematic diagram of the transceiver incorporated into thehub illustrated in FIG. 9A.

FIG. 10 is a schematic diagram of the exemplary physiological transducerillustrated in FIG. 7.

FIG. 11 is an exemplary block diagram of the server applicationarchitecture in accordance the present invention.

FIG. 12 is a diagram illustrating an exemplary message exchange betweena patient monitoring device and a hub for the system in accordance withthe present invention.

FIG. 13 is an exemplary software flow diagram for synchronizing thepatient monitoring device to a hub in accordance with the presentinvention.

FIGS. 14 and 15 are exemplary flow diagrams illustrating the hub to webserver synchronization.

FIG. 16 is an exemplary flow diagram illustrating the data server/portalto user interaction in accordance with the present invention.

FIGS. 17-24 are exemplary screen shots for use with a web-basedembodiment of the present invention.

DETAILED DESCRIPTION OF THE INVENTION

The present invention relates to a patient monitoring system formonitoring various physiological characteristics of a patient, such asblood pressure, pulse rate and others, as discussed below. The systemincludes a portable physiological transducer or patient monitoringdevice that can be worn by a patient in both single user and multi-userapplications. The patient monitoring device is adapted to monitorphysiological characteristic data of the patient and wirelessly transmitthe data to a local hub or base station. In order to reduce thecomplexity of the system, the hub or base station is configured toautomatically transfer the data to a remote server by way of a public orprivate communication network. In accordance with an important aspect ofthe invention, the system is configured to selectively enable access toa patients' physiological data by various selectable third party users,as well as the patient. In accordance with another aspect of the presentinvention, the patient monitoring system provides enhanced functionalityrelative to known systems. For example, the system in accordance withthe present invention enables selectable third party users, as well asthe patient, to monitor trends in the data for the physiologicalcharacteristics, as well as set alarms, which can automatically generatecommunications with the patient and/or third parties when aphysiological characteristic exceeds a predetermined value. Thesecommunications can be, for example, by e-mail or pager. In oneembodiment of the invention, a bi-directional communication link isprovided between the patient monitoring device and the local hub. Thisbi-directional communication link allows communications to be sent tothe patient monitoring device, for example, to remind a patient to takea physiological reading. The bi-directional communication link alsoallows handshaking between the patient monitoring device and the localhub to insure the transfer of physiological data to the local hub.

As will be discussed in more detail below, the system in accordance withthe present invention can be utilized in a wide variety of applications.For example, FIG. 1 illustrates a single user/single hub application.FIG. 2 illustrates a multiple user/multiple hub application. FIGS. 3 and4 illustrate a multiple user/single hub environment, for example, acardiac rehabilitation facility in which each of the patients wear aportable heart monitor during cardiac rehabilitation.

FIGS. 5-10 illustrate exemplary hardware diagrams for the portablephysiological transducer and the hub for use with the present invention.In particular, FIG. 5 illustrates an exemplary block diagram of aportable physiological transducer for relatively complex transducers,such as a electrocardiograph. FIG. 7 illustrates an exemplary blockdiagram of a relatively simple portable physiological transducer, forexample, a blood pressure transducer. Both transducers illustrated inFIGS. 5 and 7 may include an audio or visual indicating device to enablereminder messages to be sent to the patient monitoring device. FIG. 6illustrates a block diagram of a exemplary self contained hub or basestation for use with the present invention. FIG. 8 illustrates a blockdiagram of an exemplary hub that is adapted to be connected to amiddleware device. FIG. 9A is a schematic diagram of a self containedhub illustrated in FIG. 6. FIG. 9B is a schematic diagram of thetransceiver incorporated into the hub, illustrated in FIG. 9A. FIG. 10illustrates an exemplary schematic diagram for a relatively simplepatient monitoring device, such as a blood pressure monitor.

FIGS. 11-16 relate to the software. FIG. 11 is a block diagram of theserver application architecture. FIG. 12 is an exemplary block diagramillustrating an exemplary message exchange between a portablephysiological transducer or patient monitoring device and the selfcontained hub in accordance with the present invention. FIG. 13 is anexemplary software flow diagram illustrating the synchronization of thepatient monitoring device with the hub in accordance with the presentinvention. FIGS. 14 and 15 illustrate the synchronization of the hub tothe web server. FIG. 16 illustrates an exemplary flow diagramillustrating the data server to user interaction in accordance with thepresent invention.

In one exemplary embodiment of the invention, the system is configuredas a web portal. In this embodiment, the server is configured as a webserver and selectively allows third party access as well as access bythe patient to the physiological data transmitted by the portablepatient monitoring device. In addition, the system can be used toprovide aural and/or visual signals to the patient monitoring device toremind a patient to take readings. As discussed above and as will bediscussed in more detail below, various third parties, such as thephysician and/or relatives, as well as the patient, can not only accessthe physiological data of the patient but also view trends of such dataand also set alarms which automatically generate messages to either thepatient and/or other third parties when the physiologicalcharacteristics of the patient exceed a preset value. In accordance withthis embodiment, various screen shots as illustrated in FIGS. 17-23 areprovided.

System

FIGS. 1-4 illustrate various system applications for the patientmonitoring system in accordance with the present invention. Inparticular, single user/single hub applications, as well as multipleuser/single hub and multiple user/multiple hub applications are withinthe broad scope of the present invention. As such, the patientmonitoring system in accordance with the present invention can be usedin a relatively wide variety of applications from non-clinicalapplications, such as a home healthcare and health club applications, aswell as various clinical applications.

Referring first to FIG. 1, an embodiment of a patient monitoring systemis illustrated and generally identified with the reference numeral 30.The patient monitoring system 30 illustrates a single user/single hubapplication, for example, a home healthcare application. In thisapplication, the patient monitoring system 30 includes a portablephysiological monitor or patient monitoring device, identified with thereference numeral 32, a local hub 34, a middleware device 36, which mayor may not be incorporated into the hub 34, as well as a remote server38. The patient monitoring device 32 can be one of multiple portablephysiological transducer, such as a blood pressure monitor, heart ratemonitor, weight scale, thermometer, spirometer, single or multiple leadelectrocardiograph (ECG), a pulse oxymeter, a body fat monitor, acholesterol monitor or a signal from an exercise machine, such as aheart rate. As will be discussed in more detail below, the patientmonitoring device 32 is a portable device worn by the patient andincludes a single or bi-directional wireless communication link,generally identified with the reference numeral 40, for transmittingdata from the patient monitoring device 32 to the local hub or receivingstation 34 by way of a wireless radio frequency (RF) link using aproprietary or non-proprietary protocol.

In this embodiment of the invention, the system includes a local hub orreceiving station 34 which wirelessly receives data from the patientmonitoring device 32 and automatically communicates it to a middlewaredevice 36, which may be a personal computer, an Internet gateway, a homegateway, a phone, a video phone, or a phone modem. Alternatively, themiddleware device 36 may not be required if the hub 34 includes its ownprocessing equipment, as will be discussed below. In particular, themiddleware device 36 may form part of the hub 34.

The hub or receiving station 34 may be a receiver or transceiver forreceiving data from the patient monitoring device 32. Communication, ifrequired, between the hub 34 and the middleware device 36, may be overvarious communication links, such as a direct connection, such a serialconnection, USB connection, Firewire connection or may be opticallybased, such as infrared or wireless based, for example, home RF, IEEEstandard 802.11a/b, Bluetooth or the like.

The middleware device 36 transfers the data received by the hub orreceiving station 34 to a remote server 38. The communication linkbetween the middleware device 36 and the remote server may be by directconnection, such as a serial connection, USB, Firewire or opticallybased such as infrared or wireless based such as home RF, IEEE standard802.11b, Bluetooth or others. For longer distances, a communication linkbetween the middleware device 36 and a remote server 38 may be by DSL,T-1 connection over a private communication network or a publicinformation network, such as the Internet.

In accordance with one aspect of the invention, the remote server 38 maybe configured to provide third party access to the patient physiologicaldata forming a portal. The portal, for example, a web portal, allows thepatient and/or third party users, such as relatives and physicians, tointeract with the patient data in various ways as discussed below.

FIG. 2 illustrates a multi-user/multi-hub application of the presentinvention, generally identified with the reference numeral 42. In thisembodiment, three (3) exemplary patient monitoring devices 44, 46 and 48are used to transmit data to multiple hubs 50 and 52. The hubs 50 and 52transfer the data to middleware devices 54 and 56, which, as discussedabove may be a personal computer (PC) 54 or a phone line, web phone orvideo phone 56 or may be integrated into the hubs 50 and 52. In thisembodiment, the middleware devices 54 and 56, in turn, transmit the datato a remote server 58. In accordance with an important aspect of theinvention, various third parties, such as a physician or relatives, canselectively access the patient physiological data in the server 58, asindicated by the function block 60.

FIGS. 3 and 4 illustrate a multi-user/single hub application, for use inmultiple user applications, such as a retirement home. Two embodimentsof this application are contemplated as illustrated in FIGS. 3 and 4.Referring first to FIG. 3, the patient monitoring system is generallyidentified with the reference numeral 62. The patient monitoring system62 includes a patient monitoring device 64, a hub 66, an ID reader 68, amiddleware device 70 and a remote server 72. The patient monitoringdevice 64, hub 66, middleware device 70 and the server 72, as well asthe communication links therebetween, are as described above. In theexemplary application illustrated in FIG. 3, the ID reader 68 isoperatively connected to the hub 66 to accommodate different users in amultiple user environment. In such an application, each user is given aunique ID. This ID is input into the hub 66. Various types ofidentification are contemplated. For example, the ID reader 68 may be aswipe card, RF tag or push button. In this embodiment, the user ID isread from the ID tag of the user at the same time physiological data isbeing read from the patient monitoring device 64.

FIG. 4 illustrates an alternative embodiment of the inventionillustrated in FIG. 3. This embodiment is generally identified with thereference numeral 74. The patient monitoring system 74 includes apatient monitoring device 76, a hub 78, a server 82 and an ID reader 84.The patient monitoring system 74 is similar to the patient monitoringsystem 62, illustrated in FIG. 3, except that the patient monitoringsystem 74 is configured such that the ID reader 84 is coupled to thepatient monitoring device 76. In this embodiment, the user ID andphysiological data is transmitted together to the hub 78. In lieu of theID reader, the patient monitoring device 76 can be configured such thatthe device transmits an unique ID with the physiological data. Thus,different users wearing different devices can easily be correlated bythe system.

Hardware

The hardware for the patient monitoring device, as well as the hub, isillustrated in FIGS. 5-10. As mentioned above, FIGS. 5 and 7 relate to apatient monitoring devices, generally identified with the referencenumerals 84 and 85, for use with the present invention. FIGS. 6 and 8illustrate exemplary hubs for use with the present invention. FIG. 10 isan exemplary schematic diagram of the patient monitoring device 84,illustrated in FIG. 5.

Exemplary Patient Monitoring Devices

Various embodiments of the patient monitoring devices 84 and 85 arecontemplated. Both embodiments may optionally include a visual or audioindicating device to allow visual and/or audio communications to be sentfrom the system to the patient monitoring device. The patient monitoringdevice 85 (FIG. 7) is representative of patient monitoring devices whichutilize relatively simple transducers, such as a blood pressure monitor,heart rate monitor and others. The patient monitoring device 85 includesa transducer 88, such as a blood pressure transducer, coupled to acommunication module 90. The communication module 90 may include amicroprocessor 92, a memory real time clock 94, as well as a transmitterfor unidirectional communications or a transceiver 96 which enablesbi-directional communication between the patient monitoring device 85and a local hub, as discussed above. An audio or visual indicatingdevice 93 may also be provided to enable alerts or messages to be sentto the patient monitoring device 85. The transducer 88 may be directlywired to the communication module 90, as indicated by the electricalleads 98. An antenna 100 is provided in order to provide a wireless linkto the local hub, as discussed above. A power supply 102, such as abattery may be provided.

The MCU 92 may be, for example, Motorola model number 68HC908GP32. Theradio 96 may be, for example, a Xemics model number XE 1201. The memory94 may be, for example, an Atmelmodel number CAT 24AA65. The real timeclock may be a Dallas Semiconductor model number DS 1675.

More sophisticated patient monitoring devices 84, as illustrated in FIG.5, such as electrocardiograph (ECG) devices, may include one or moretransducers which directly communicate with a microprocessor 106. Aninput/output (I/O) device 108 may be directly coupled to themicroprocessor 106, for example, for receiving data from electrodesattached to the patients' body by way of electrical leads (not shown).As is well known in the art, this data is received by the microprocessor106 and configured by the transducer 104 and communicated to acommunication module 110. The communication module 110 includes its ownmicroprocessor 112, a memory 114 such as an electrically erasableprogrammable read only memory (EEPROM), a radio 114 for bi-directionalcommunication or simply a transmitter for unidirectional communication,as well as an antenna 116.

Various physiological transducers can be integrated into the system.These transducers are similar to various commercially availabletransducers such as: a blood pressure transducer, such as A&D bloodpressure cuff, model number UA-767PC; a weight scale, such as an A&Dscale, model number UC-321; a blood glucose meter, such as a LifeScanONE TOUCH.RTM. Ultra; a pulse oximeter, such as a PalmSat Model 2500; aspirometer, such as a Micro Direct model MICRO DL; a prothromben timetest for Coumadin.RTM. therapy, such as a PT/NR Protime MicrocoagulationSystem; and a cholesterol monitor, such as a LSP 3101 PersonalCholesterol Monitor Kit. Virtually any physiological transducer whichgenerates an electrical signal can be implemented in the system.

Hub Hardware

Exemplary block diagrams for the hub for use with the present inventionis illustrated in FIGS. 6 and 8. Referring first to FIG. 8, the hub 87includes a radio 116, a microprocessor 118 and a memory/real time clock120. The hub 87 also includes and an antenna 120 and a power supply 122if required. This embodiment of the hub 87 is for an embodiment in whichthere is a separate communication link as discussed above to amiddleware device 122 for embodiments in which the middleware device 122is separated from the hub 87.

FIG. 6 illustrates an alternative embodiment of the hub, identified withthe reference numeral 86 in which the middleware device is integrallyformed with the hub. In this embodiment, the hub 86 includes a radio 126and an antenna 128 for receiving data, wirelessly from the patientmonitoring device. The hub 86 also includes a microprocessor 130, a realtime clock 132, a memory device such as a EEPROM 134 and a modem 136.The microprocessor 130, radio 126, real time clock 132 and memory 134may be as discussed above. The modem may be a ConnectOne embeddediModem, Model Number iM336UC-EM.

FIG. 9A is an exemplary schematic diagram of the hub 86 illustrated inFIG. 6. FIG. 9B is an exemplary schematic diagram of the transceiver 126illustrated in FIG. 9A.

Software

FIGS. 11-16 illustrate the system software. FIG. 11 illustrates theserver application architecture. FIG. 12 illustrates the messageexchange between a patient monitoring device and the hub. FIG. 13illustrates the software for synchronizing data from the patientmonitoring device to the hub. FIG. 14 illustrates the synchronizationbetween the hub and the remote server and specifically relates to userregistration. FIG. 15 illustrates the software flow diagram forinteraction between the hub and the web server. FIG. 16 illustrates thesoftware flow diagram for interaction between the user and dataserver/portal.

Referring first to FIGS. 13-16, FIG. 13 illustrates the software forcontrolling the patient monitoring device and transmitting the data fromthe patient monitoring device to the hub. Initially, in step 138, onpower up, the patient monitoring device, either on its own or inresponse to patient input, begins taking readings of a patientphysiological characteristic. These readings are stored in the patientmonitoring device along with a time stamp and device ID in step 140. Instep 142, the patient monitoring device sends out RF signals with its IDin an attempt to locate a local hub. If no hub responds as indicated instep 144, the patient monitoring device stores the data and goes tosleep in step 146. Subsequently, after a preset time, the device awakensin step 148 and returns to step 142 and attempts to locate a hub.

Once a hub is located, the hub responds with a handshake signalindicating that it is available to receive data as indicated in step150. After the handshake, the hub may communicate various information tothe patient monitoring device in step 152. For example, the hub may senda message to the patient monitoring device indicating that previousreadings have been received. The hub may also send a message to thepatient monitoring device with the current date and time to update thatdevice. In addition, the hub may send reminders at specified dates andtimes to remind a patient when to take readings for those patientphysiological devices which do not constantly take readings. Finally,the hub may also send a message to the patient monitoring device tochange the frequency or baud rate of the communication. Subsequently, instep 154, the patient monitoring device synchronizes its date and timestamp and deletes all previous readings to the date and time in order toinitialize the patient monitoring device. After the patient monitoringdevice is initialized in step 154, the patient monitoring device thensends the data to the hub in step 156 with its associated ID and dateand time. The patient monitoring device may also send data to the hubindicating that its battery is low. In step 158, the hub acknowledgesreceipt of each message received.

The message exchange between the patient monitoring device and the hubis illustrated diagrammatically in FIG. 12. Initially, as indicated inbox 160, the patient monitoring device on power up sends a query to thehub, as indicated by the message 162. The hub in response to that querychecks whether the ID number for the patient monitoring device islisted, as indicated by the block 164. In addition, the hub may alsocommunicate its local date and time as well as control information withrespect to clearing the log and frequency change, as message 164. Thisinformation is acknowledged and acted upon by the patient monitoringdevice, as indicated by the message 168. After the patient monitoringdevice is time synchronized with the hub, the patient monitoring devicebegins sending data to the hub along with its ID and time stamp, asindicated by the message 170.

The above message exchange may be identified as a pre-cycle messageexchange. Such a pre-cycle message exchange is identified as a timeperiod when the patient monitoring transducer is not actively recordingdata such as during a time period when a blood pressure cuff has notbeen inflated.

After the data has been transmitted from the patient monitoring deviceto the hub, post cycle messages include repeating the messages 162 and166 after each data cycle has been completed. In addition, a message 172may be sent from the patient monitoring device to the hub for the firstpiece of data, indicated by the box 174. After the hub receives the data174, it sends a message back to the patient monitoring device indicatingthat the data 174 has been received. Once the patient monitoring deviceacknowledges from the hub that the first bit of data has been received,additional data is sent by way of a message 178 to the hub, as indicatedby the data block 180. The hub responds that the data 180 was receivedby way of a message 182 back to the patient monitoring device. After allof the data has been transmitted from the patient monitoring device tothe hub, the patient monitoring device sends a message 184 indicatingthat the next bit of data is the last bit of data in the memory to besent by the patient monitoring device by way of the message 184. The hubthen acknowledges receiving the last bit of data 186 by acknowledging byway of message 188 back to the patient monitoring device 188 that it hasreceived that data 186.

FIGS. 14 and 15 illustrate the synchronization between the hub and theremote server. In accordance with an important aspect of the invention,the server in this embodiment is configured as a portal, for example, aweb portal, which enables third party users to selectively accesspatient physiological data transferred to the remote server. In thisapplication, users register on the portal and create an account in step190. In step 192, the user registers one or more devices (i.e. deviceID's) with their account. Next, in step 194, the list of registereddevices for a particular user is synchronized with the hub therebyenabling the hub to receive data for the specified device IDs. In step196, the hub filters wireless communications from various patientmonitor devices and only responds to data originating from registereddevices. In step 198, any updates of the registered devices with respectto a user's account are synchronized with the hub.

FIG. 15 illustrates a software diagram for transferring data between thehub and the remote server. Initially, in step 200, data is received bythe hub as discussed above. In step 202, the data may be stored, forexample, in XML format, for example, and optionally encrypted withreadings with unsynchronized time stamps, which may be corrected to bestestimates. In step 204, if the hub is not connected to the server, theserver looks for an Internet connection or creates a connection over aLAN/phone line automatically and sends the data to the web server whenconnection is established. In step 206, data is uploaded to the webserver and associated to a device ID and user. The web server respondsin step 208 by sending messages to synchronize the data including a timeand date stamp of last received data (clear log); a list of date andtime stamps for reminders; and may include a down load list of deviceIDs associated with that hub.

FIG. 16 is a software flow diagram used to control the dataserver/portal in connection with user interaction. Initially, in step210, data is received by the data server from the hub. In step 212, thedata may be decrypted and staged for acceptance by the user after a userlogs in. Subsequently, in step 214, the data is cataloged in a user datarepository or database to enable the user to interact with the data inmeaningful ways like display charts, tables and trigger alarms andtrends. As indicated in step 216, the data may be checked against presetrequirements for alerts and trends. These alerts and trends may be shownto the user in step 218 in various ways on a web page, a pager, atelephone, an e-mail to a selected list of people to be informed. Theweb server may then display the charts and tables in step 220. Thereports and tables can be exported to spreadsheets and/or e-mailed tothird parties in step 222 for review. In step 224, the server allowsadditional third party access for the various data in step 224.

As indicated in step 226, when connection, such as Internet connection,is established between the hub and the server, the server sends the hubvarious messages. These messages may include the current device ID listfor the user to the hub. The messages may also include date and timestamps for reminders and the date/time stamp of the last updatedreading.

Web Pages

In a exemplary embodiment, as discussed in detail below, the remoteserver may be configured as a web portal. Exemplary web pages for apatient monitoring system are illustrated in FIGS. 17-24. In particular,FIG. 17 illustrates exemplary home page generally identified with thereference numeral 228. This web page 228 includes a registration box 230and an account box 232. The registration box 230 allows patients toregister and unregister various physiological characteristicmeasurements. The account box 232 provides a summary of a patients'alert and trends. The account box 232 includes links 234 and 236 toscreens where alerts and trends can be set.

FIG. 18 illustrates a exemplary web page 238 which allows a user, eithera patient or a third party user, to track data by way of a displaywindow 240. The exemplary web page 238 allows a user to track data, viewit by device type, change the time scale as well as annotate the data.FIG. 19 is an exemplary web page which allows a user to view data intabular form. On this page, the time range and device data can beselected by the user. FIG. 20 is an exemplary web page 244 which enablesa user to set reminders for the device to provide reminders, eitheraurally or visually at certain times or at periodic intervals. FIG. 21is an exemplary web page 246 which allows a user to set alert parameterson absolute values and to specify how to receive the alerts via browser,e-mail, voicemail, pager, etc. In particular, “My Account” boxesgenerally identified with the reference numeral 248, allow theparticular message link to be selected. FIG. 22 illustrates an exemplaryweb page 250. The web page 250 allows a user to set up parameters,baselines and trends. FIG. 23 illustrates an exemplary web page 252which may be used by a clinical administrator to monitor a summarystatus of all assigned patients including the last reading and anyalerts generated. FIG. 24 illustrates an exemplary web page 254 for useby an administrator to view the devices registered by various users inthe system.

Server Application Architecture

FIG. 11 illustrates the server application architecture. The serverapplication architecture may include four levels or tiers 228, 230, 232,234. The tier 228 may be a user or client tier which allows users tointeract with the underlying application. This client tier translatesuser actions and inputs them as server requests and formats a serverresponse, usually visual. The client tier may be a client, such as abrowser, or a custom application running on a hub or specific devicessuch as wired, wireless handheld Personal Digital Assistants (PDAs). Theclient tier may also be a non-user action, such as automated services,such as Internet Explorer.

The web tier 230 makes application functionality available on theworldwide web. This tier 230 accesses data and business functionalities,manages screen flow and often encapsulates some user interaction. It maybe used to decouple the client from the business logic tier 232 toprovide a uniform service model of client request. The web tierinteracts with other tiers using standard protocols. Other applicationsmay take place of the client programs accessing the underlyingapplication through its web tie, such as Apache/Tomcat.

The business logic tier 232 encapsulates the business logic andcomprises the software application functionality. The logic is organizedas a set of interacting objects allowing for additions and enhancementof the logic at any point while still preserving the interface of othertiers. This business logic tier 232 may be implemented using J2EE,Microsoft.NET or a custom architecture, such as Tomcat.

The data access tier 234 may be used to integrate the application withother enterprise information systems. This tier 234 provides datastorage and other information services to the application. It mayconsist of a database, enterprise resource planning systems, mainframetransaction processors, legacy systems and enterprise integrationtechnologies. Other tiers access these databases using industry standardor custom protocols such as Oracle.

Web Portal Details

As mentioned above, in one exemplary embodiment of the invention, a webportal (hereafter referred to as the portal) provides meaningful accessto a patient's personal health data, as collected by the patientmonitoring device(s) and stored in a server-based data repository(hereafter referred to as the repository). Some key mechanisms of theportal are listed below and are explained in further detail insubsequent sections. These key mechanisms include:

-   -   A mechanism for self-registration of devices by the user.    -   A mechanism to synchronize data between the Repository and        device(s) via the Receiving Station.    -   A mechanism to allow the user to preview the readings received        from the device(s) and reject erroneous readings.    -   A mechanism to generate alerts against received data, based on        user defined parameters.    -   A mechanism to determine trends in received data, based on user        defined parameters.    -   A mechanism to match computed trends with visual perception of        the trend.    -   A mechanism to set reminders on the device(s). This mechanism        can be extended to set up any arbitrary “event” on the device(s)        e.g. local alert generation.    -   A mechanism by which a clinician may monitor a group or a number        of users via a summary “dashboard” of their readings data, with        ability to drill-down into details for each user.    -   A mechanism to enhance user (healthcare) education by providing        a healthcare questionnaire dynamically created (and updated)        based upon certain rules applied to recent user readings data.    -   A mechanism to provide data feeds (i.e. export, either “raw” or        aggregated) to external systems with transformations between        appropriate data formats.

Device Registration Through Portal

Device registration is the process by which a patient monitoring deviceis associated with one or more users of the system. This mechanism isalso used when provisioning devices for a user by a third party, such asa clinician (or their respective delegate). The mechanism is as follows:

1. The user (or delegate) identifies himself/herself by logging into theportal. The user must have previously registered an account createdeither by themselves or by delegates.

2. User (or delegate) registers a device by:

-   -   a. Choosing from a list of kinds of devices available for        registration.    -   b. Providing identification information for the device such as        manufacturer information, device model information, device        serial number (available on device packaging) and optionally a        hub number (available on hub packaging). The user may register        more than one device at this point.    -   c. Optionally setting up a service subscription for device(s)        usage. This includes selecting service plans and providing        payment information.

3. The device(s) are then associated with this user's account and aDevice Control File (discussed below) comprised of device identificationinformation is synchronized between the server and the Receiving Stationon initialization (see the section Data Synchronization betweenReceiving Station and Repository). This enables the Receiving Station torespond to and accept input from the devices that have theiridentification information in the control file.

4. On each interaction between the hub and the server, the control fileentries for the current user (or hub) are synchronized.

5. Similarly, whenever the user registers a device, its entry is addedto the control file on the hub if not already there on the nextsynchronization interaction with the server.

6. No association information between the actual user (person) and thedevice is kept on the user's hub. This determination is made after thedata is uploaded to the server.

7. The hub may be shared between users and data for all users residenton the hub is uploaded to the server on synchronization.

Device Control File

This file contains records in the format

-   -   <device id>, <data update timestamp>    -   where <device id> is all the information required to uniquely        identify a device to the system (such as manufacturer number,        model number, serial number and user number) and the <data        update timestamp> is the timestamp (including date) that data        for this device was last received by the server. Note that this        is not the timestamp for which data was last uploaded from this        particular hub (on which the control file resides) but is the        timestamp for which the server last received data (from any hub)        for the particular (registered) device. Additional information        for controlling the device(s) e.g. reminder information is also        maintained in this file.

This file is internally maintained in XML format for ease of interfacingbut is either kept encrypted or in a non-readable format on the hub forsecurity reasons.

User Data File

This file contains records in the format

-   -   <device id>, <reading timestamp>, <reading data>    -   where <device id> is as described in the section Device Control        File. The <reading timestamp> is the time of the reading and the        <reading data> is a data record in a format specific to the type        of reading. This file is internally maintained in XML format for        ease of interfacing but is kept encrypted or in a non-readable        format on the hub for security reasons.

Data Synchronization Between Receiving Station and Repository

The hub and the Repository frequently synchronize data. The hub may useone of various transportation methods to connect to the repository e.g.using a PC as conduit or via a connection established using an embeddedmodem (connected to a phone line) or via another network-connecteddevice (such as, but not limited to, a web-phone, video-phone, embeddedcomputer, PDA or handheld computer). The mechanism is as follows:

1. When a user logs into the portal, the User Data File, resident on thehub, is uploaded to server. The server filters duplicate readingsrecords.

2. Alternatively, the Data Synchronization Client may upload the datafrom the hub to the Server without user intervention automatic datasynchronization without user intervention also happens in the case of astand-alone hub.

3. The data may be decrypted on the server, assigned to each user (bydetermining which user the device is registered with) and put into astaging area. This staging area is so that the user may optionallypreview the data before accepting the values. The server also filtersfor duplicate reading values.

4. The device control file is uploaded to the server.

5. The server downloads updated device control file with last updatedtimestamps for each device in list. If device has been removed from thesystem, then its entry in the file is deleted. The old device list fileis backed up.

6. The data file is cleared/deleted.

Data Synchronization Client

There is often the need for the reading data to be uploaded to theserver without explicit user intervention. The Data SynchronizationClient runs on the hub to upload the user's data to the server whilesynchronizing the information contained in the control file.

Alerts

Users may set up alerts that are triggered when one or more reading meeta certain set of conditions, depending on parameters defined by theuser. The mechanism is as follows:

1. The user sets up an alert by choosing the condition that they wouldlike to be alerted to and by providing the parameters (e.g. thresholdvalue for the reading) for alert generation.

2. Each alert thus set up has an interval associated with it. Thisinterval may be either the number of data points or a time duration inunits such as hours, days, weeks or months, depending on the type ofreading for which this alert is being set up.

3. The values of readings lying within the interval specified by theuser must all either positively or negatively exceed the specifiedthreshold for the alert to be generated i.e. there is an implied “and”across all the readings within the interval.

4. The user chooses the destination where the alert may be sent. Thisdestination may include the user's portal, e-mail, pager, voice-mail orany combination of the above.

5. Specific, preset alerts are provided based on medically establishedconditions in the case of common reading types e.g. heart rate, weight,blood sugar etc. The user may modify the parameter values for thesealerts if they so desire.

Trends

The system computes trends in the user's data values over an interval.The mechanism is as follows:

1. Trends are determined by applying mathematical and statistical rules(e.g. moving average and deviation) over a set of reading values. Eachrule is configurable by parameters that are either automaticallycalculated or are set by the user.

2. Currently the system tracks deviations from baseline values (seesection Baselines) either automatically calculated using intelligentdefaults or provided by the user.

3. The user also supplies a range over which the trend is calculated.This is specified either as the number of data points or a numericalunit of time (e.g. hours, days, weeks etc, depending on reading type).

4. This range is always applied backwards from the most current readingi.e. if the user specifies that the trend needs to be calculated overthe past 5 days, then the system will calculate the trend of the past 5days from current date.

5. The system displays the deviation between the trend values computedfrom received data and the baseline value. This deviation is indicatedboth as a percentage as well as a numerical difference, along with icons(“+”,“−”,“=”) to visually indicate the trend direction.

Baselines

6. The system may be used to calculate a baseline value for each readingtype using algorithms specific to each reading type. The user canoverride the default baseline average by changing the default parametersused to calculate the baseline e.g. the start date and the number ofreadings. Additionally, the user may directly provide baseline value(s)into the system, overriding the computed baseline values. If the userprovides parameters such that there is insufficient data for calculatingthe baseline, then the system alerts the use to the fact. Previously setbaseline values are not altered.

During early use of the system, there may be insufficient data forautomatically calculating baselines for the user's reading types. Inthis case too, the system alerts the user to the fact.

Strength of Trend Correlation

The system may contain algorithms to compute the strength of the trendand correlate it to the visual perception of the trend as would beobserved by a human observer.

Example Algorithm: In order for a weight trend to be visually perceivedas increasing or decreasing, a certain positive or negative standarddeviation from a moving average baseline must be observed over apre-defined time period to be able to inform the user that their weightis either increasing or decreasing.

old-baseline = calculate moving average for initial data rangeold-standard-deviation = 0 for each subsequent interval   new-baseline =calculate moving average for updated data range   new-standard-deviation= standard-deviation(new-baseline, old- baseline)   if(new-standard-deviation > 0)     then trend is increasing     ifstandard-deviation(new-standard-deviation, old-standard-  deviation) > 0      then strength of trend is increasing     else strength of trend isdecreasing   else if (new-standard-deviation < 0)     then trend isdecreasing     if standard-deviation(new-standard-deviation,old-standard- deviation) > 0       then strength of trend is increasing    else strength of trend is decreasing   old-baseline = new-baseline  old-standard-deviation = new-standard-deviation

Reminders

The user may set up reminders on the device(s) via the portal. Thedevice then draws the user's attention at the appointed time e.g. bysounding a buzzer. The mechanism is as follows:

1. Each device associated with the user's account has its ownindependent set of reminders.

2. Each reminder can be made repeatable. The user can set the reminderto repeat every n<units of time> (where <units of time> may be hours,days etc.) starting from a preset date and time.

3. The reminders are associated with a user's account and aresynchronized with the device(s) via the hub. The reminder information ismaintained in the control file (see section Device Control File).

4. The user can specify their time zone so as to account for differencesbetween time on the server vs. the user's local time.

Buddy or Role Based Access

The user may give permission to others as needed to read or edit theirpersonal data. This is useful, for example, for allowing a well-wisherto view ones data/charts, or receive alerts. The clinician could beallowed to edit data for example to annotate it, while the patient wouldhave read-only privileges and that too for certain pages. An authorizedperson could set the reminders and alerts parameters with limited accessto others.

The user or clinician could have a list of people that they want tomonitor and have it show on their “My Account” page, which serves as thecentral monitoring station. The central monitoring concept could beparticularly useful in an environment where on person wishes or needs tomonitor multiple people.

Clinician Administrator

A clinician administrator (also referred to as Administrator in thiscontext) may monitor the data for and otherwise administer a number ofusers of the system (also referred to as Patients in this context). Themechanism is as follows:

1. A summary “dashboard” of readings from all Patients assigned to theAdministrator is displayed upon log in to the Portal by theAdministrator. At a minimum, the Patient's last reading received fromall devices is shown (color coded to visually distinguish normal vs.readings that have generated an alert), along with description of thealert generated.

2. The Administrator may drill down into the details for each Patient tofurther examine the readings data, view charts etc. in a manner similarto the Patient's own use of the system.

3. The Administrator may also view a summary of all the devicesregistered to all assigned Patients, including but not limited to alldevice identification information.

4. An Administrator has access only to information about Patients thathave been assigned to the Administrator by a Super Administrator. Thisallows for segmenting the entire population of monitored Patientsamongst multiple Administrators.

The Super Administrator may assign, remove and/or reassign Patientsamongst a number of Administrators.

Patient Questionnaire

The Portal provides a mechanism to enhance the healthcare interactionand education of the users of the system (also referred to as Patientsin this context). The mechanism is as follows:

1. A questionnaire may be made available to the Patient containingquestions pertinent to their health condition.

2. The Patient's answers to the questions are stored and tracked by thetime of each “session” (user interaction). Statistical summaries ofthese answers for various intervals of time are available for display.

3. The Administrator (or delegate) defines the entire set of questionsthat may be made available to all Patients. Of these, pertinentquestions are selected based on rules applied to the Patient's recentdata in the Repository.

Data Export and Reporting

Data may be extracted, exported and reported from the Repository into avariety of formats, both application specific and industry standard. Themechanism is as follows:

1. The data in the Repository is internally extracted into a neutralformat represented in XML.

2. This data is further processed to either aggregate information or toremove user identification information, as may be the specificrequirement.

3. The internal, neutral format may be transformed into custom,application specific formats or industry standard formats depending onspecific application requirements.

Software Architecture Specification

Requirements

The architecture for the web application meets the requirements below.In particular, the architecture must be relatively independent of theuser's client environment. At a minimum, the most common browsers(Netscape 4.0 and higher, IE 4.0 and higher) are supported on Windows(95, 98, NT, ME, 2000 now, XP in the near future). In addition, thearchitecture must be continuously adaptable to support newly emergingand evolving business requirements. This includes changes in thepresentation, the business logic as well as the data tier.

In addition, the architecture should meet the following characteristics:

-   -   Scalable to meet performance levels as the user base grows, with        the cost of scaling contained for at least 300,000 users.    -   Support rapid, iterative development. It is based on the J2EE        Blueprints reference architecture with its timeline adapted to        our schedule.    -   Not require expensive development tools. Most of the development        tools are available free as either open source or extended        evaluation versions.    -   Being based on industry-standard interfaces, it must allow for        significant functionality to be purchased off-the-shelf (with        integration and possible customization).

By adapting a standard reference architecture, it allows for the timerequired for developers to gain familiarity with the architecture to becompressed provided they are well versed in J2EE technology andarchitecture. This allows for the development effort to be outsourced ata later point in the development cycle. Moreover, the standardarchitecture, supports rapid and frequent changes to the look of theapplication. Such an architecture also supports the division of laboramongst the development team e.g. the application is partitioned suchthat the front-end designer requires minimal programming knowledge andvice versa.

The architecture should also partition the application to allow for thebusiness logic to be accessed via a variety of interfaces e.g. the web(HTML) for now, wireless (WML) and/or voice response (VRU) in thefuture. It should also accommodate internationalization and localizationof the application in the near future without significant changes. Inaddition, the architecture should leverage emerging technologies toprovide a superior user experience e.g. it does not require the user todownload, install and configure complicated software by utilizingemerging server-side technology. Moreover, the architecture should havea growth path to allow use of new technology as it becomes availableover the application's lifespan (5 years). It should be designed to beresilient for at least the next 1-2 years while accommodating change.Finally, the architecture should not be tied to a particular set ofproducts i.e. any J2EE compatible server can serve as application host.It also is relatively independent of database. This allows forflexibility in choosing and switching between hosting providers.

Technology

Platform

The Java 2 Enterprise Edition (J2EE) may be used as the standardtechnology platform for this application. Of the available J2EEcomponents, the initial development phase may use Java Server Pages(JSPs), servlets, Java Database Connectivity (JDBC), Java API for XMLProcessing (JAXP). Other J2EE components, such as Enterprise Java Beans(EJBs), transactions APIs etc. may be used as required for subsequentdevelopment phases. Using J2EE components has the following advantages:

-   -   Simplified architecture and development    -   Scalability to meet demand variations    -   Integration with a variety of databases    -   Choices of servers, tools, components    -   Flexible security model

Relevant J2EE Features and Components

Scalability

J2EE provides mechanisms that support simplified scaling of distributedapplications, without requiring significant effort on the part of theapplication development team. Because application services such astransaction support, database connections, life cycle management etc.are provided by the platform, the application can leverage thesecapabilities by adhering to the rules requiring it to be compatible withthese services. For example, by using the appropriate JDBC APIs,connection pooling is automatically available for increased performance.Similarly, J2EE servers now provide many scaling mechanisms that werepreviously designed by the application developer.

Declarative Security

Security (access restriction, authentication) is configureddeclaratively at deployment time instead of being coded at developmenttime. This allows for continuous refinement of the security mechanism(matching users with roles, with groups of users having specific accesspermissions) without requiring changes to the code followed byredeployment. For comparison, commercial products providing these kindsof capabilities for web applications (e.g. getAccess from EntrustTechnologies) are typically priced at $15-$25 per user for quantitiesless than 5000 users.

Expandability

As the functionality provided by the J2EE expands, these capabilitiesare immediately available for use by the application. For example, theConnector architecture in the upcoming release of the J2EE will providebuilt-in capabilities of communicating with legacy systems (oncecommercial implementations are available).

Supported by Hosting Services

There are several commercial and open source implementations of J2EEcompatible servers with the result that most hosting services offerreasonably priced hosting packages for J2EE applications.

Other Enabling Technologies and Products Page Layout and Rendering

Flash

The pages should be as lightweight as possible while being aestheticallypleasing. This leads to using Flash as the rendering technology foritems such as buttons and image maps etc. since this leads to compactgraphics. However, there are no large animations.

CSS

The pages should not be hard-coded for a particular user screen sizei.e. pages may be designed using Cascading Style Sheets (CSS).

Charting

Popchart (http://www.popchart.com) from Corda may be used to providecharting functions. It runs as an image server and services requests forcharts from the web server over a pre-configured TCP port. It supportsmultiple output formats (including Flash, WML and SVG) and good chartinteraction such as pop-up text and drill-down. The charts can bevisually designed by a graphic designer and later renderedprogrammatically.

Reporting (Printing)

The reporting technology/product should support the followingrequirements:

-   -   It must be able to produce charts similar in nature to those        produced on-screen for the user.    -   It must be able to export the user's data in Excel format for        download.    -   It must be able to provide the user with the facility to print a        report on his/her local printer.    -   It must be able to provide the user report in PDF format for use        as an e-mail attachment.    -   The final choice of product is still pending. Among the products        evaluated include Formula One from Tidestone Technologies and        Style Report from Inetsoft Corp.

Development Tools User Interface

Visual Design

Dreamweaver software may be used as a tool for developing the front-endHTML. Flash and (optionally) Fireworks software can be used along withDreamweaver. MS Frontpage software, although popular, is not preferredsince it introduces irrelevant HTML into each document.

Chart Design

Popchart software (see section Charting above) includes a graphics chartbuilder that allows charts to be interactively designed. The designermay use this builder to create aesthetically pleasing charts.

HTML Validation

All HTML should pass validation for acceptance. Tidy is one utility thatcan check HTML for validity.

Web Server

An Apache web server may be used for development. The deployment webserver is provided by the hosting service.

Servlet Engine

Tomcat software may be used for development due to it providingintegrated debugging with many IDEs (Integrated DevelopmentEnvironments) and its smaller memory footprint when compared with othersimilar commercial products.

Framework

J2EE Blueprints (JPS)

The current application architecture is modeled after the J2EEBlueprints reference application (the Java Pet Store version 1.1.1).Although EJBs are not used at this stage, the tier separation ismaintained to allow them to be introduced at a later stage.

com.oreilly.servlet

This is a collection of utility classes available at www.servlets.comthat may be useful in servlet development. Developed and maintained byJason Hunter, author of the book Java Servlet Programming, 2nd Ed. (mustread).

Java Code

Integrated Development Environment

Forte for Java, Community Edition may be used because it provides a richfeature set for free. JRun Studio has also been evaluated and may beused if we switch to JRun in a later development phase.

JSP Tag Libraries

Tag libraries from the Apache-Jakarta (and the Struts framework) projectmay be used if needed. Proprietary taglibs will not be used. Taglibsshould be used if their use results in significant effort saving.

Code Documentation

Javadoc.

Build Tool

Any industry standard build tool (such as Ant or make) can be used asthe build tool.

Unit Testing

The JUnit unit-testing framework (wwwjunit.org) may be used to unit testall developed code. Extensions to JUnit for server-side testing and J2EEtesting (e.g. HttpUnit, Cactus) may also be used.

Database

Either Oracle or MS SQL Server 2000 may be used as the database. It isimportant to be careful to not have dependencies on the database toallow for switching if required by hosting providers.

Process Control

Configuration Management

Visual SourceSafe or CVS may be used. CVS is accessible over theInternet.

Bug Tracking

EbugStomp software may be used for web-based bug tracking.

Application Architecture Request and Response Flow

This section describes the architecture of the application: exploringthe partitioning of functionality into modules, the assignment offunctionality to tiers, and object decomposition within the tiers.

Application Structure

Modules

This is a list of the functional modules of the system. Some of themodules are relatively simple but have been broken out to provide anidea of the broad functional areas of the application.

Control Module

This module provides the basic framework for the other functionalmodules. It provides key features such as navigation, security etc.

User Account Module

This module maintains information about a person's account (contactinformation, payment and credit card information) as well as the devicesassociated with a particular account.

User Profile Module

This module maintains information about a person's profile such asdemographic information, medical conditions, medications and allergies.

Device Information Module

This module maintains information about the various types of devicessupported by the system.

Data Synchronization Module

This module provides the functionality to upload the newly acquiredreadings data from a user's PC to the server. It flags potentiallyerroneous readings and provides a preview of the data so that the usermay optionally reject some readings. Please refer to the section DataSynchronization between User's PC and Server for more details.

Data Management Module

This module manages the data obtained for each user. It also providesfunctionality to associate annotations with data points.

Data View: Charts Module

This module provides the functionality for the user to view his/herreadings data as charts. The user may choose to view either presetranges of data or choose an arbitrary range.

Data View: Tables Module

This module provides the user with a tabular view of their data. Thereare no complex table-editing functions.

Trends Module

This module contains the logic to provide the user indication of certaintrends in their data.

Alerts Module

This module provides the functionality where the user can select frompreset patterns to look for in the data to be alerted about. The usermay choose certain parameters of the triggering events e.g. if theirblood pressure is above X for Y days, then trigger an alert, where X andY are chosen by the user.

Reminders Module

The reminders module generates preset reminders to a user about certainevents that were supposed to have occurred but have not.

Groups Module

This module will provide functionality in which the user can choose toinvite another registered user to be a part of his/her group. Theinvited user can then have access to the inviting user's data.

E-Mail Module

This module provides the functionality to send e-mail arising from anumber of places in the application: when an alert is generated, forsending a user report etc.

Report Module

The report module will provide functionality to generate simple reportsfor the user incorporating charts.

Print Module

This module will provide the functionality to print on the client PC.

Export Module

This module provides the capability to export the user's data in Excelformat.

Interfaces

The web application will have the following interfaces with externalsystems. These interfaces may be either synchronous (i.e. online, inreal time) or asynchronous (i.e. as a batch operation, deferred intime).

Interface with Credit Card System

The application will transmit the user's credit card number and obtainonline verification. It will also make periodic charges to the creditcard as the user's account is automatically renewed on expiry.

Interface with E-Store

An outsourced e-store will provide the capability for a user to buy adevice online. The application should be able to transfer informationsuch as credit card information etc. to this system. Additionally, thefront-end for such a system needs to be created and integrated with therest of the application.

Interface with Refund Generation System

This system will generate pro-rated refund checks for users cancelingtheir accounts. The application must transfer the required informationto this system.

Interface with Customer Support System

A customer support system providing (at least) e-mail based supportneeds to be integrated with the application/site.

Interface with Device Control Software on the User's PC

At this time, the interface with the device control software running onthe user's PC is asynchronous and is handled by uploading anddownloading files to a known location on the user's disk. This willeventually be enhanced to obtain the file location from the Windowsregistry.

Key Mechanisms Business Object Framework

The Business Object Framework (BOF) is designed as a lightweightstand-in for Enterprise Java Beans (EJBs). The idea is to createstructural parallels with the EJB component structure (such as the homeand remote interfaces, session and entity beans etc.) in a simple objectframework that allows for easy migration to EJBs at a later time. Thekey differences between EJBs and BOs are:

There is no container that the BOF objects (and their derivedobjects/components) run in. Because of that, BOF-derived objects mustmanage their own lifecycle such as creation and destruction. This ishowever minimal and is abstracted behind utility (factory) methods.

BOF-derived objects are generically referred to as BOs (for businessobjects) and are packaged in the bo package within the applicationstructure. The scope of BOs is the same as for regular Java objects.This is different from EJBs, whose scope is controlled by the containerand managed by methods on the home interface. The BO implementationobjects must directly implement the BOF equivalent of the remote andhome interfaces i.e. the BOInterface and BOHome. This is a keydistinction from EJBs, in which the implementation object does notdirectly implement its home and remote interfaces.

The methods in the BOHome that are implemented by the BO have the samenames as defined in the interfaces. This is different from EJBs whichhave a naming convention of prefixing ejb to the method name e.g.ejbCreate for a method named create in the home interface. BOs extendeither the SessionBO or EntityBO base class. This is different fromEJBs, which instead implement either the SessionBean or EntityBeaninterfaces. BOs are not remotely referenced and execute in the local JVMinstead.

Components

The BOF has the following main types of components as set forth below:

Business Object Interface

This is the equivalent to the EJB remote interface. All business processmethods are defined in this interface. Interfaces of this type extendcom.carematix.bof.BOInterface and are named per the EJB convention i.e.using the domain class name. The BO must implement this interfacedirectly.

Business Object Home (Interface)

This interface is the equivalent of the EJB home interface. At the veryleast, it must define a create( . . . ) method to return a concrete BOobject implementing the BOInterface. Interfaces of this type extendcom.carematix.bof.BOHome and are named per the EJB convention i.e. byappending “Home” to the domain class name. The BO must implement thisinterface directly.

Business Object

This is the abstract base class (com.carematix.bof.bo) for SessionBusiness Objects (SBOs) and Entity Business Objects (EBOs) describedbelow.

Session Business Object (SBO)

An SBO is the equivalent of a session EJB. One key distinction is thatSBOs can only be stateless, not stateful beyond the scope of the callingmethod. It is best to assume them as stateless. Typically, SBOs definemost of their methods in the BOInterface and have just a simple create() method in the BOHome interface. A session BO extends the base classcom.carematix.bof.SessionBO.

Entity Business Object (EBO)

An EBO is the equivalent of an entity EJB and encapsulates somepersistent data representation. Typically, EBOs have a simpleBOInterface and have most of their methods in the BOHome interface suchas create ( . . . ), load ( . . . ), store ( . . . ), remove ( . . . ),findByPrimaryKey ( . . . ) etc. Not all of these methods are required inevery EBO and only those needed by the application must be defined. Anentity BO extends the base class com.carematix.bof.EntityBO.

EXAMPLES

Source code for the placeholder classes comprising the BOF is available.Accompanying that are two example packages: boexample1 and boexample2.These provide example implementations for a session BO and entity BOrespectively. They illustrate the patterns and conventions required tocreate BOs and should be thoroughly studied.

Usage

In order to access a BO from calling code, the following example of ahandler method for handling account events is illustrative:

     public  void  perform(PWMAppEvent  event)  throwsPWMAppEventException  {   AccountEvent ae = (AccountEvent)event;    ...  switch (ae.getActionType( ))    {     caseAccountEvent.CREATE_ACCOUNT:     {      try      {       UserHomeuserHome = BOUtil.getUserHome( );       User user = userHome.create( );      user.createAccount(ae.getUserId( ), . . .);       ...       }      catch (DuplicateKeyException dke)       {       ...       }      // Catch more exceptions     }   }  }

Deployment

Entries need to be created in the web.xml file for each BO in order toenable JNDI lookup. Entries for the BO examples are as follows:

    <?xml version=“1.0” encoding=“ISO-8859-1”?>     <!DOCTYPE web-appPUBLIC ‘-//Sun Microsystems, Inc.//DTD Web  Application 2.2//EN‘ ‘http://java.sun.com/j2ee/dtds/ web-app.sub.--2.2.dtd- ‘>    <web-app>     . . .     <env-entry>    <env-entry-name>bo/boexample1/Example1</env-entry-name>    <env-entry-type>java.lang.String</env-entry-type><env-entry-value>com.carematix.boexample1.bo.Example1SBO</env-entry-value>    </env-entry>     <env-entry>    <env-entry-name>bo/boexample2/Example2</env-entry-name>    <env-entry-type>java.lang.String</env-entry-type>     <env-entry-value>com.carematix.boexample2.bo.Example2EBO</env-entry-value>    </env-entry>     <env-entry>     <env-entry-name>bo/boexample2/Example2DAOClass</env-entry--name>    <env-entry-type>java.lang.String</env-entry- type><env-entry-value>    com.carematix.boexample2.dao. Example2DAOImpl</env-entry-value>    </env-entry>      . . .     </web-app>

Template Mechanism

The XML-based templating solution provides many benefits. XML is auseful, consistent way of representing application parameters. The XMLformat is easy to use for both presentation specialists and third-partytools. The fact that XML is standardized means we can use off-the-shelfsoftware to handle all the details of parsing and writing our screendefinitions, configuration files, and other forms of structured data.Finally, XML can be validated against a DTD (Document Type Definition),so the parser can handle errors relating to ill-formed input, instead ofin the application code.

Three files control the templating system:

The template file (template.jsp), which defines the basic layout of allof the pages generated from the template. There is one template file persupported language.

The request mappings file (requestmappings.xml), which maps virtual URLsto screen names (or request handler classes). There is one requestmappings file in the application.

The screen definitions file (screendefinitions.xml), which defines theparameters for each screen. There is one screen definitions file persupported language.

The main controller servlet MainServlet receives incoming HTTP requests.MainServlet matches the incoming URLs to the URLs defined in the requestmappings file, obtaining a screen name. The template parameterscorresponding to the screen name are retrieved from the screendefinitions file, and the template is then served using thoseparameters. The MainServlet does not do all of the work. Most of thework is delegated to other classes that specialize in screen flowmanagement, template instantiation, and the like.

The XML files in the templating system are parsed by a standard XMLparser, created using the JAXP (Java API for XML Parsers) optionalpackage. The template is served as a JSP page, and the inclusion of thedynamic content occurs because the JSP engine calls the custom tag<j2ee:insert> each time it occurs.

In a Web application, each screen presented to the user can beconsidered as a different view. However, unlike the classic MVCarchitecture, all these views share the same controller. There needs tobe a mechanism that allows the controller to choose a particular view torender in response to a user request. In the sample application, thecontroller makes this selection by specifying the screen ID of thescreen to present as the response. This screen ID is mapped to a screendefinition, then the template is instantiated. Recall that the filetemplate.jsp defines the template for the sample application. This fileincludes another file, ScreenDefinitions.jsp, which defines all thescreens of the sample application. When the controller invokes thetemplate file at request time, it sets the appropriate screen definitionin the request scope. The template file passes this information to thescreen definitions file which then returns the appropriate screendefinition for the request. One goal in structuring template and screendefinition files is to facilitate internationalization (discussed inSection 4.5). This is achieved by separating text content from Javacode. Since screen definitions that contain direct and indirectparameters are candidates for internationalization, we want to keepScreenDefinitions.jsp devoid of Java technology code. We achieve thisthrough the use of JSP custom tags.

Data Access Mechanism

The application uses a bimodal data access mechanism to increaseefficiency of data access. Since it is anticipated that the majority ofdata access will be read-only (50% or more, as a conservative estimate),the data access mechanism will not utilize a transactional component forreading, relying instead on direct JDBC access to reduce overhead.Conversely, data updates will still continue to rely on a transactioncomponent. When a transactional update does occur, the model will berefreshed from the data store and a model update event propagated to allregistered views to update themselves, ensuring data displayconsistency.

Data Synchronization Between User's PC and Server

The functional specifications for the data synchronization mechanism arelisted below, followed by details on each of the components thatimplement the mechanism. In cases where the implementation details of acomponent is not yet decided (such as whether to use an applet or not onthe client PC), it is referred to generically (e.g. data sync client).

Functional Specifications

When a user logs on to the home page (FIG. 17) using the PC the datafile is uploaded to server. The server filters duplicate readingsrecords. The records are decrypted on the server, assigned to each user(by determining which user the device is registered with) and put into astaging area. This staging area is so that the user may optionallypreview the data before accepting the values. The device control file isuploaded to the server. The server downloads updated device control filewith last updated timestamps for each device in list. If device has beenremoved from the system, then its entry in the file is deleted. The olddevice list file is backed up. The data file is cleared/deleted. If auser has logged onto the site for the first time from this PC, then anew control file is downloaded. This control file will contain entriesfor the registered devices of the current user only and will be built upas other users log into the PC. Similarly, when a user registers adevice, its entry is added to the control file on the PC if not alreadythere.

For this phase of implementation, the locations of the control file andthe data file on the user's PC is fixed. Note the following:

-   -   No association information between the user and the device is        kept on the user's PC. This determination is made after the data        is uploaded to the server by matching the device id against the        RegisteredDevice table.    -   Data for all users (i.e. from all devices in the control file)        is uploaded to the server, regardless of the user logged on.

Device Control File

This file contains records in the format

-   -   <device id>, <data update timestamp>    -   where <device id> is all the information required to uniquely        identify a device to the system (such as manufacturer number,        model number, serial number and user number) and the <data        update timestamp> is the timestamp (including date) that data        for this device was last received by the server. Note that this        is not the timestamp for which data was last uploaded from this        particular PC (on which the control file resides) but is the        timestamp for which the server last received data (from any user        PC) for the particular (registered) device.

User Data File

This file contains records in the format

-   -   <device id>, <reading timestamp>, <reading data>    -   where <device id> is as described in the section Device Control        File. The <reading timestamp> is the time of the reading and the        <reading data> is a data record in a format specific to the type        of reading. Each record in the file is individually encrypted        (encryption to be implemented in a subsequent phase) and is        appended to the end of the file. Note that data for all users is        aggregated in the same file.

Data Synchronization Client

This client runs on the user's PC to handle the file operations to andfrom the server such as uploading and downloading, checking for fileexistence, creating backup files etc. Note that these are all fileoperations and do not require any business logic in this client. All ofthe business logic decisions are made at the server and the appropriatefiles are downloaded. This allows for the client to be implemented as asigned applet.

A standalone Data Synchronization Client that does not require a PC andis directly able to connect to the server via a network connection isdeveloped by embedding the synchronization logic in the firmware of amicrocontroller and using it to connect to the server through aconnection established either via a phone line (which requires anembedded modem) or via a connection established by another networkterminal such as a web-phone or video-phone to which the DataSynchronization Client is connected.

Data Synchronization Manager

The Data Synchronization Manager component runs on the server and is theprimary interface between the Data Synchronization Client and the restof the application. Its primary operations include: receiving upload ofthe data file from Data Synchronization Client; decrypting the datarecords; determining which user each record belongs to (fromRegisteredDevice mapping); putting each user's respective records instaging area (table) for user preview if so specified. This function isactually delegated to the ReadingsManager; putting each user'srespective records in data tables if user does not want preview. Thisfunction is actually delegated to the ReadingsManager; signaling DataSynchronization Client to delete data file; receiving upload of controlfile; if control file does not exist, then creating it initially;updating control file with last uploaded timestamp for each registereddevice; downloading updated control file to Data Synchronization Client.

The Data Synchronization Manager has the following invocation points:

-   -   On user login.    -   On user registering one or more device(s).    -   On user previewing uploaded data prior to accepting it.    -   On an embedded Data Synchronization Client connecting to the        server.

The Data Synchronization Manager is implemented as a Session BO as wellas a standalone server application known as the iModem server.

IModem Server and Protocol Specification

The key attributes and mechanisms of the iModem server (i.e. DataSynchronization Manager for Standalone Data Synchronization Clients)are:

Accept multiple connections over the same server port at the same time:This will happen (in production) since more than one iModem could beconnecting to the server and will require that the server bemulti-threaded, using an independent thread for handling eachconnection. This is somewhat analogous to how web servers handle HTTP,which is a stateless protocol wherein several clients connect over thesame port (80) at the same time. This also implies that the port numberto which the iModem connects will remain constant.

Build in a versioning scheme into the protocol: This allows for upgradesover time without breaking backward compatibility.

Provide a status value in each message response. Zero indicates OK,non-zero values indicate various error conditions.

Error handling: There must be enough error handling and recoverabilitythat a user's data is never lost and that each end (iModem or server)can signal to the other that data transfer either occurred or not. Theremust also be timeouts to handle conditions when no response is achieved.The value of the timeout (in seconds) must be a parameter read from aconfiguration XML file.

Break down current messages into multi-step messages: This is to handletwo basic limitations: 1) each message to and from the iModem must beless than 256 bytes and 2) the iModem embedded code is more efficient inparsing fixed-length responses rather than variable length responses.

Encryption and keys: A basic mechanism (using placeholders as necessary)needs to be put in place such that in case the data stream isintercepted by a third party, all information that is private to thepatient (such as reading values) and all information that can becorrelated to deduce the message format (such as device identificationinformation) is scrambled or encrypted.

This servlet is a “listener” for an embedded internet-modem (iModem)that has established a dial-up connection with a PPP server and is thencommunicating over TCP/IP to a specific server and port. The primarypurpose of this servlet is to accept TCP connections over the specifiedport, parse the data coming over the connection and return responses. Italso does basic connection management of connections and sockets asnecessary. The incoming data stream comprises a series of messages in asimple protocol detailed below. This servlet parses the data stream,decodes the protocol message and responds based on logic detailed below.In summary, this servlet serves as a protocol handler for the iModem hubdata transmission, which is done over TCP/IP sockets.

IModem Protocol.

The data protocol is a variant of the data exchange (XML) protocol thatis used by the main web application for data interchange (defined by thefiles devicecontrol.xml and readingsdata.xml, hereafter referred to asthe Datasync protocol). It differs from the Datasync protocol in thefollowing manner to allow for the limited processing requirements of theiModem hub:

Numeric values are specified as hexadecimal text with each byte valuecomprised of 2 ASCII characters i.e. a decimal value 1085, which is 43Dhex (or 043D hex, more accurately), will be specified as the characters‘0’, ‘4’, ‘3’ and ‘D’. The most significant byte (MSB) is first whendecoding multi-byte values.

Descriptive tags in the Datasync protocol are replaced with 4-digithexadecimal numbers referred to as tokens. E.g. a <control-entry> tagmay be denoted as <04AD>.sup.1. The mapping of the tags in the Datasyncprotocol to the iModem protocol must be configurable via another XMLfile (tagmappings.xml) so that it may be changed as the protocolsevolve. End tags are denoted by a 4-digit hex number that is calculatedby setting the most-significant-bit (MSB) of the number denoting thestart tag. This defines the start tag and end tag relationship of theiModem protocol..sup.1 The angle braces < > will still be used tosurround tags

Readings are sent serially as a series of Readings Data messages (seebelow). This is given the current limitation of the iModem restrictingthe message length to be less than 256 bytes. The server response iseither a success or error indicator.

All timestamps are in seconds elapsed since Jan. 1, 1970, denoted as a4-byte number and encoded as the ASCII representation of the hex digits,MSB first. There is an additional command for getting the current servertime that is not part of the Datasync protocol. The details of thismessage are defined below, with a descriptive tag being used in place ofa token for illustration purposes.

Initiate Session

Command

    <initiate-session><hub-id>H3H2H1H0</hub-id><protocol-version>P1P0</protocol-version></initate-session>

Response

    <initiate-session><status>S1S0</status><current-time>T3T2T1T0</current-time><update-flag>F0</updateflag><key>K1K0</key><initate-session>

Details

The HubID is an identifier that is encoded in the iModem hub and istransmitted as a means of identifying itself. It is a long i.e. 4 bytenumber. This ID will be populated in the database through the deviceregistration UI (which will be enhanced to support this later) and isused to associate a user (and his registered devices) with a specifichub.

On receiving this message, the server should set up a “session” withthis connection and Hub ID and return a status code of 0000 in theresponse. All subsequent messages coming over this connection areconsidered in the context of the established session. If an unrecognizedHub ID is received, a status code of 0001 is returned with other messagedata being same. The <protocol-version> value is two byes, with the MSBbeing the major version and the LSB being the minor version. Socurrently, this value would be 0101 (current version is 1.1=>1<<8+1=257decimal=0101 hex, formatted as 2 characters for each byte).

The response returned is the current server time, in seconds elapsedsince Jan. 1, 1970. It is a 4-byte number and is encoded as the ASCIIrepresentation of the hex digits, MSB first.

There are two additional fields added for version 1.1. These are theupdate-flag and key. <update-flag> is a byte value that is used tosignal to the iModem that there are parameter updates (see messageParameter Updates) that it needs to query for. The intent is to providea way for parameters such as dial out numbers, dialing prefixes etc. tobe provisioned via a web interface and indicated to the iModem so thatit can update its own memory-based parameters. For version 1.1, thevalue returned is always 00 (zero).

The <key> is a placeholder value for now. It is a 16 bit number and itsvalue is always 0000 (zero).

Parameter Updates Command <param-updates></param-updates> Response<param-updates><status>S1S0</status></param-updates&- gt;

Details

This is a placeholder message for now and will be expanded in futureprotocol revisions. The status code is always 0000.

Readings Data

Command

  <readings-data><reading-record><device-id><manufacturer-no>M2M1M0</manufacturer-no><device-model>D2D1D0</device-model><serial-no>N3N2N1N0</serial-no><user-no>U0</user-no></device-id><timestamp>T3T2T1T0</timestamp><reading><reading-type>BP-HR</reading-type><units>mm    Hg</units><values><bp-systolic>V0</bp-systolic><bp-diastolic>V0</bp-diastolic><pulse-rate>V0</pulse-rate></values></reading><-/reading-record></readings-data>   Response  <readings-data><status>S1S0</status></readings-data>   Details

This message is a fixed-format equivalent to the readingsdata.xml filecontaining a single reading. The appropriate token values (as set up intagmappings.xml file) are used for <reading-type> and <units> tagvalues.

The <status> value is a 16-bit integer. The value 0000 (zero) indicatesno error whereas non-zero values indicate error conditions. Currently,only the value 0001 is assigned as a general error indicator. This listof values will be expanded over time and the code should be written toallow for it without significant change.

Because the iModem requires a fixed-length, fixed-format data command,the server must do some conversion/transformation to derive theapplication-specific XML <readings-data> command. The iModem will alwayssend all data (BP, weight or blood sugar) in the format described above(for BP). The only difference for weight and blood sugar will be thatthe <reading-type> and <units> will correspond to the type of reading,so that for weight, <reading-type> value is WEIGHT and <units> value isPOUNDS and for blood sugar, <reading-type> is BLOODSUGAR and <units>value is mg/dL. The value of the reading is derived from the byte valuescontained in the <bp-systolic>, <bp-diastolic> and <pulse-rate> tags.Because of this, the <value> tag is no longer required.

The server must use the following algorithm/logic to convert these fixedformat iModem <readings-data> commands to the Datasync protocol's<readings-data> messages:

if (reading-type == BP-HR)    then  translate  iModem <readings-data> message directly  into Datasync <readings-data> messageelse if (reading-type == WEIGHT)   then     value = ((<bp-diastolic> <<8 + <bp-systolic>) >> 6) * 2.2     // this value is in POUNDS, << & >>are left-shift & right- shift operations else if (reading-type ==BLOODSUGAR)   then     value = <bp-systolic>

Number of Devices

Command

<device-control-list></device-control-list>

Response

    <device-control-list><status>S1S0</status><num-devices>N0</num-devices></device-control-list>

Details

This command is used to obtain the number of devices currentlyregistered by the user. The status is generally expected to be 0000,non-zero indicates an unspecified (as of yet) error.

Device Information

Command

<device-info><device-num>N0</device-num></device-info>

Response

    <device-info><status>S1S0</status><control-entry><device-id><manufacturer-no>M2M1M0</manufacturer-no><device- model>D2D1D0</device-model><serial-no>N3N2N1N0</serial-no><user-no>U0</user-no></device-id><reminders></reminders><first-association-timestamp> T3T2T1T0</first-association-timestamp><last-update-timestamp> T3T2T1T0</last-update-timestamp></control-entry></device-info>

Details

The iModem sequentially requests device details for each deviceregistered by the user, passing in a device number (actually, deviceindex) as part of the command. The list is zero-indexed i.e. the firstdevice is 0 (zero) and the index increments sequentially from there. Theinformation in the response is the same as a single-entry device controlfile. Currently, nothing is returned for reminders (even if there aresome set) since the iModem is not set up to handle them. These will behandled in a subsequent protocol revision.

Terminate Session

Command

<terminate-session></terminate-session>

Response

This command does not return a response.

Details

This command is for the iModem to indicate to the server that it is donewith the session prior to terminating the connection so that the servermay release resources and perform other cleanup. The server does notreturn a response to this command since the client's state is undefinedafter this. It releases resources and terminates the server's socketconnection.

Reminders

Reminders are in a slightly different format from the Datasync protocol.The structure is as follows:

    <reminders><reminder><start>T3T2T1T0</start>-<repe   at>nn</repeat><for>nn</for></reminder>; . . . </reminders>

-   -   where . . . denotes more reminder records, each delineated by a        <reminder></reminder> sequence. Each reminder block is part of        the <control-entry> block. The <repeat> value is the number of        seconds to repeat the reminder after the start. It is zero if        there is no repetition. The <for> value is the number of times        this repetition must be carried out. It too is zero if there is        no repetition.

Chart Creation and Display

The chart creation and display mechanism is comprised of collaboratingobjects and components across all four application tiers (view, web,business object and data persistence tiers). As previously mentioned,Popchart is the charting server being used to render the data fordisplay in the Flash format. This requires the Flash plug-in to beinstalled in the client browser, which the majority of the browsers(over 90%) already do.

The approach to chart creation and display is to isolate dependency onPopchart in the view tier only. This is to allow change over to anothercharting product if required later. Doing this requires encapsulatingall code to create a Popchart chart in presentation components in theview tier. All the information (data) required to produce the chart iskept as generic objects or components and supplied to the viewcomponents via the standard application framework. This mechanism iselaborated upon below.

The View Tier

This tier is comprised of the JSP page containing the chart as well asan embedded JavaBean that converts the chart model objects into Popchartspecific instructions (there may be the need to do specific JavaBeansfor each chart type but the approach will remain the same for each).This JavaBean encapsulates the logic to create Popchart instructionsfrom the chart model objects and isolates the dependency on Popchart.

The Popchart JSPExample demonstrates such a JSP/JavaBean combination.The key points of difference are:

-   -   The example code has a lot of hard-coded elements such as label        information etc. All this information is being supplied in the        chart model object(s) instead.    -   The example code has a lot of direct database access for        retrieving data. All data required to create the chart will be        supplied through the chart model object(s) or in objects        directly associated with them. Some of these data objects would        be the domain model objects themselves e.g. the Range object        would contain the range of reading values to be charted.

The Web Tier

This tier contains the standard web handler for processing user input tothe chart (such as when a user displays the chart, changes the daterange, clicks on a point for annotation or drill-down etc.). The handlercreates a chart event object (class ChartEvent) encapsulating the userrequest and forwards it to the Business Object tier for handling.

Note that there may be requests that can be handled in the web tieritself instead of having to go to the BO tier. For example, the user maychoose to view a data range that is a subset of the range alreadydisplayed. In this case, there is no need to go to the BO tier to getdata for display since the data has already been sent to the web tier inthe chart model object(s). The web tier handlers need to be intelligentenough to check for these cases in order to improve applicationperformance.

The Business Object Tier

This tier contains the components required to handle chart eventsgenerated from the web tier. The main facade component is a session BOnamed ChartManagerSBO. This BO interprets the chart event andcreates/retrieves the chart model objects that are required to generatethe requested chart. It invokes the ReadingsManager to get the actualreadings model objects. This BO also provides the defaults for chartpresentation.

The chart model objects also belong in this tier. These objectsencapsulate the complete information required to render the chart. Thisincludes information about the various chart display parameters as wellreferences to the model objects that hold the actual data for display.The data used to populate the chart model is obtained from thechartconfig.xml file using a DAO implementing the ChartDAO interface.

The chart model object is mutable i.e. it can be changed when a useradds or changes annotations on data points. The annotation actuallychanges a particular reading referenced by the range, which is in turnreferenced by the chart model object.

Implementation Notes

Popchart servlet redirector may be used.

The implementation DAO object actually is ChartXmlDAOlmpl, meaning thatit reads the XML configuration file.

The elements in the chart model object that are specific to the chartingproduct are kept as properties so as to not make the structure of themodel object dependent on product-specific attributes.

Patterns

Following are the design patterns utilized in the architecture. Furtherdetails can be found in publicly available J2EE Blueprints documents aswell as in a book, entitled “Design Patterns”, by Vlissides, Gamma, etal and are thus elaborated upon further here.

Model-View-Controller (MVC)

Data Access Object (DAO)

Bimodal Data Access

Front Component

Value Object

File Formats

Device Control File

This file is currently in plain text XML format. It may later be storedencrypted if necessary. It does not currently have a DTD and thereforerequires a non-validating parser. For now, the URI for this file isfile://c:.backslash.carematix.backslash.config.backslash.devicecontrol.xml.

  <?xml version=“1.0” encoding=“ISO-8859-1”?>   <device-control-list>   <control-entry>     <device-id>      <manufacturer-no>12345</manufacturer-no>      <device-model>67890</device-model>      <serial-no>555555555</serial-no>       <user-no>1<user-no>    </device-id>    <last-update-timestamp>06-05-200111:21:33</last-update- timestamp>    </control-entry>   <!-- More<control-entry> records for all other devices that    users of this PChave registered with Carematix.   -->   </device-control-list>

User Data File

This file is currently in plain text XML format. It may later beconverted into a format in which each XML <reading-record> entry isencrypted and stored as a fixed length record, with new records beingappended to the end. It does not currently have a DTD and thereforerequires a non-validating parser. For now, the URI for this file isfile://c:.backslash.carematix.backslash.data.backslash.readingsdata.xml.

Note: This file may contain duplicate <reading-record> entries. That isallowed.

<readings-data>  <!-- Reading record for blood pressure and heart ratereading -->  <reading-record>    <device-id>    <manufacturer-no>12345</manufacturer-no>    <device-model>67890</device-model>    <serial-no>555555555</serial-no>     <user-no>1<user-no>   </device-id>    <timestamp 06-05-2001 11:21:33 PM/>    <reading>   <!-- The reading-type tag may be eliminated later -->   <reading-type>BP-HR</reading-type>    <values>    <bp-systolic 120 />   <bp-diastolic 80 />    <pulse-rate 72 />    </values>   </reading></reading-record> <!-- Reading record for temperature reading --><reading-record>   <device-id>   <manufacturer-no>29933</manufacturer-no>   <device-model>68909</device-model>   <serial-no>123456789</serial-no>    </device-id> <timestamp06-05-2001 11:21:42 PM/> <reading> <!-- The reading-type tag may beeliminated later -->  <reading-type>TEMP</reading-type>   <!-- The unitsfor temperature are FARENHEIGHT   or CELCIUS   <units FARENHEIGHT />  <value 98.7 />   </reading> </reading-record> <!-- Reading record forweight reading --> <reading-record>   <device-id>   <manufacturer-no>29890</manufacturer-no>   <device-model>68309</device-model>   <serial-no>123456789</serial-no>    </device-id>   <timestamp06-05-2001 11:25:42 PM/>   <reading>   <!-- The reading-type tag may beeliminated later -->  <reading-type>WEIGHT</reading-- type>   <!-- Theunits for weight are KILOGRAMS or POUNDS -->   <units KILOGRAMS />  <value 65 />  </reading>  </reading-record> ... more reading recordsfrom all devices (and all users) </readings-data>XML to iModem Tag Mappings

    <tag-mapping   type=“request”  xml-tag=“readings-data”  imodem-tag=“0000”/>   <tag-mapping   type=  “request”  xml-tag=“reading-  record”  imodem- tag=“0001”/>   <tag-mapping type= “request”xml-tag=“reading” imodem -tag=“0002”/>   <tag-mapping type=“request” xml-tag=“reading-type” imodem-  tag=“0003”byte-length=“1”>     <tag-token xml-token=“BP-HR” imodem-token=“04”/>    <tag-token xml-token=“TEMP” imodem-token=“05”/>     <tag-tokenxml-token=“WEIGHT” imodem-token=“06”/>   <tag-tokenxml-token=“BLOODSUGAR” imodem-token=“07”/>   </tag-mapping>  <tag-mapping type=“request” xml-tag=“values” imodem-tag=“0004”/>  <tag-mapping type=“request” xml-tag=“bp-systolic” imodem- tag=“0005”byte- length=“1”/>   <tag-mapping type=“request” xml-tag=“bp-diastolic” imodem-  tag=“0006”byte-length=“1”/>   <tag-mapping type=“request” xml-tag=“pulse-rate”imodem- tag=“0007” byte- length=“1”/>   <tag-mapping type=“request” xml-tag=“units” imodem-  tag=“0008” byte- length=“1”>    <tag-token xml-token=“mm Hg” imodem-token=“00”/>     <tag-tokenxml-token=“Kelvin” imodem-token=“01”/>     <tag-token xml-token=“POUNDS”imodem-token=“02”/>     <tag-token xml-token=“mg/dL” imodem-token=“03”/>  </tag-mapping>   <tag-mapping  type=“response” xml-tag=“current- time” imodem-tag=“0009” byte-length=“4”/>   <tag-mapping type=“common”xml-tag=“device-id” imodem- tag=“000A”/>   <tag-mapping  type=“common”  xml-tag=“manufacturer-   no”  imodem- tag=“000B”byte-length=“3”/>   tag-mapping  type=“common” xml-tag=“device- model” imodem-tag=“000C” byte-length=“3”/>   tag-mapping type=“common” xml-tag=“serial-no” imodem-  tag=“000D” byte-length=“4”/>   tag-mapping  type=“common” xml-tag=“user-no” imodem- tag=“000E” byte- length=“1”/>   tag-mapping  type=“common”  xml-tag=“device-control-   list”  imodem- tag=“000F”/>  tag-mapping type=“response” xml-tag=“control- entry”imodem-tag=“0091”/>   tag-mapping type=“response” xml-tag=“reminders”imodem- tag=“0092”/>   tag-mapping type=“response” xml-tag=“reminder”imodem- tag=“0093”/>   tag-mapping type=“response” xml-tag=“start” imodem-  tag=“0094” byte- length=“4”/>  tag-mapping  type=“response” xml-tag=“repeat” imodem-  tag=“0095”byte-length=“4”/>   tag-mapping  type=“response” xml-tag=“for” imodem- tag=“0096” byte- length=“1”/>   tag-mapping type=“request” xml-tag=“timestamp” imodem-  tag=“0097”byte-length=“4”/>   <tag-mapping   type=“response”   xml-tag=“first-association-timestamp”imodem-tag=“0098” byte-length=“4”/>   <tag-mapping type=“response” xml-tag=“last-update-timestamp” imodem- tag=“0099”byte-length=“4”/>   <tag-mapping type=“response” xml-tag=“status” imodem-  tag=“009A”byte- length=“2”/>  <tag-mapping type=“common” xml-tag=“device-info” imodem-tag=“009B”>  <tag-mapping  type=“response” xml-tag=“num-devices” imodem-tag=“009C”byte-length=“1”/>   <tag-mapping type=“request” xml-tag=“device-num” imodem-tag=“009D” byte-length=“1”/>  <tag-mapping   type=“common”   xml-tag=“initiate-session”   imodem-tag=“0030”/>   <tag-mapping type=“request” xml-tag=“hub-id” imodem-tag=“0031” byte- length=“4”/>  <tag-mapping type=“request” xml-tag=“protocol-version” imodem-tag=“0032”byte-length=“2”/>   <tag-mapping type=“response” xml-tag=“update-flag” imodem-tag=“0033”byte-length=“1”/>   <tag-mapping type=“response” xml-tag=“key” imodem-tag=“0034” byte- length=“2”/>  <tag-mapping   type=“common”  xml-tag=“terminate-session”  imodem-tag=“0035”/>   <tag-mapping  type=“common”  xml-tag=“param-updates”  imodem- tag=“0036”/>

Chart Configuration File

This file contains the necessary information for formatting anddisplaying data charts. This information is kept in XML format neutralof the specific charting product so as to allow changeover to anothercharting application if necessary later. It does not currently have aDTD and therefore requires a non-validating parser. This file is storedon the server, not the client and is called chartconfig.xml

Please note the following: this format is an initial version and willlikely be enhanced over time. The method for altering and enhancingchart display is to add tags and/or properties in the sections for eachchart and use the values assigned to each to drive the behavior of thecode. This is preferred over hard-coding the way a chart is displayed inthe code itself.

In subsequent phases, this file may have an XSL transform applied togenerate the product specific charting instructions e.g. if usingPopchart, an XSLT would be provided to generate PCScript from this XMLfile.

<chart-config>   <bp-chart>     <type>TIMELINE</type>     <title>BloodPressure</title>     <height>xxx</height>     <width>yyy</width>    <property name=“appearance-file” value=     “URL of appearance file”/>     <property name=“date-format” value=“%m/%d/%y %H:%M” />  </bp-chart>   <hr-chart>     <type>TIMESCATTER</type>     <title>HeartRate</title>     <height>xxx</height>     <width>yyy</width>    <property name=“appearance-file” value=     “URL of appearance file”/>     <property name=“date-format” value=“%m/%d/%y %H:%M” />  </hr-chart>   <temperature-chart>     <type>TIMELINE</type>    <title>Temperature</title>     <height>xxx</height>    <width>yyy</width>     <property name=“appearance-file” value=    “URL of appearance file” />     <property name=“date-format”value=“%m/%d/%y %H:%M” />   </temperature-chart>   <weight-chart>    <type>TIMELINE</type>     <title>Blood Pressure</title>    <height>xxx</height>     <width>yyy</width>     <propertyname=“appearance-file” value=     “URL of appearance file” />    <property name=“date-format” value=“%m/%d/%y %H:%M” />  </weight-chart> </chart-config>

Obviously, many modifications and variations of the present inventionare possible in light of the above teachings. Thus, it is to beunderstood that, within the scope of the appended claims, the inventionmay be practiced otherwise than as specifically described above.

1. A patient monitoring system including: a patient monitoring devicedetermining a plurality of physiological readings of a patient andwirelessly transmitting said plurality of patient readings to a wirelesshub; a wireless hub wirelessly receiving said plurality of physiologicalreadings; and a remote server, wherein said remote server receives saidplurality of physiological readings from said wireless hub and comparessaid plurality of physiological readings to a predetermined alertcondition based on a plurality of physiological readings, wherein analert indication is provided to said patient when said plurality ofpatient readings violate said alert condition.
 2. The system of claim 1wherein said alert condition is established by said patient.
 3. Thesystem of claim 1 wherein said alert condition is established by anentity other than said patient.
 4. The system of claim 3 wherein saidalert condition is established by a physician.
 5. The system of claim 1wherein said alert condition is established using a web portal to saidremote server.
 6. The system of claim 1 further including a secondpredetermined alert condition, wherein at least one of said plurality ofphysiological readings is compared to said second predetermined alertcondition.
 7. The system of claim 1 wherein said predetermined alertcondition is established using a trend in a plurality of previousphysiological readings from said patient.
 8. The system of claim 1wherein an alert indication is also provided to an entity other thansaid patient.
 9. The system of claim 8 wherein said entity is aphysician.
 10. The system of claim 1 wherein a plurality of alerts areprovided to said patient.
 11. The system of claim 10 wherein a first ofsaid plurality of alerts is provided to said patient using a firstcommunication channel and a second of said plurality of alerts isprovided to said patient using a communication channel other than saidfirst communication channel.
 12. The system of claim 11 wherein one ofsaid communication channels is a pager and another of said communicationchannels is e-mail.
 14. A patient monitoring system including: a patientmonitoring device determining a first physiological reading of a patientand a second physiological reading of a patient and wirelesslytransmitting said first physiological reading and said secondphysiological reading to a wireless hub; a wireless hub wirelesslyreceiving said first physiological reading and said second physiologicalreading; and a remote server, wherein said remote server receives saidfirst physiological reading and said second physiological reading fromsaid wireless hub, wherein said remote server includes a predeterminedalert condition that requires a plurality of physiological readings froma patient to determine whether said alert condition has been triggered,wherein said remote server uses both said first physiological readingand said second physiological reading to determine whether said alertcondition has been triggered, wherein an alert indication is provided tosaid patient when said alert condition has been triggered.
 15. Thesystem of claim 14 wherein said remote server also includes a secondpredetermined alert condition that requires only a single physiologicalreading from a patient to determine whether said second predeterminedalert condition has been triggered, wherein at least one of said firstphysiological reading and said second physiological reading are comparedto said second predetermined alert condition to determining whether saidsecond predetermined alert condition has been triggered, wherein analert indication is provided to said patient when said second alertcondition has been triggered.
 16. The system of claim 15 wherein bothsaid first physiological reading and said second physiological readingare compared to said second predetermined alert condition.
 17. Thesystem of claim 14 wherein said alert condition is established using aweb portal to said remote server.
 18. The system of claim 14 whereinsaid predetermined alert condition is established using a trend in aplurality of previous physiological readings from said patient.
 19. Thesystem of claim 14 wherein an alert indication is also provided to anentity other than said patient.
 20. The system of claim 14 wherein aplurality of alerts are provided to said patient.
 21. The system ofclaim 20 wherein a first of said plurality of alerts is provided to saidpatient using a first communication channel and a second of saidplurality of alerts is provided to said patient using a communicationchannel other than said first communication channel.
 22. The system ofclaim 21 wherein one of said communication channels is a pager andanother of said communication channels is e-mail.
 23. The system ofclaim 15 wherein a plurality of communication channels to said patientare provided and the communication channel selected to communicate analert indication varies depending upon whether said alert condition orsaid second alert condition has been triggered.
 24. A method formonitoring a patient, said method including: determining a plurality ofphysiological readings of a patient at a patient monitoring device;wirelessly transmitting said plurality of patient readings to a wirelesshub; wirelessly receiving said plurality of physiological readings atsaid hub; transmitting said plurality of physiological readings to aremote server; receiving said plurality of physiological readings fromsaid wireless hub at said remote server; comparing said plurality ofphysiological readings to a predetermined alert condition based on aplurality of physiological readings; and providing an alert indicationto said patient when said plurality of patient readings violate saidalert condition.
 25. A method for monitoring a patient, said methodincluding: determining a first physiological reading of a patient at apatient monitoring device; determining a second physiological reading ofsaid patient at said patient monitoring device; wirelessly transmittingsaid first physiological reading and said second physiological readingto a wireless hub; wirelessly receiving said first physiological readingand said second physiological reading at said hub; transmitting saidfirst physiological reading and said second physiological reading to aremote server; receiving said first physiological reading and saidsecond physiological reading from said wireless hub at said remoteserver, wherein said remote server includes a predetermined alertcondition that requires a plurality of physiological readings from apatient to determine whether said alert condition has been triggered;using both said first physiological reading and said secondphysiological reading to determine whether said alert condition has beentriggered; and providing an alert indication to said patient when saidalert condition has been triggered.